All large corporations, and many small to medium sized organizations, face significant challenges in coordinating the provisioning of resources for employees and contractors. Every time a new application is installed or a new employee is hired, administrators must create multiple directory entries to match (e.g., grant or authorize access) users to the proper resources. Thus, simple events such as a new hire can turn into a laborious exercise, requiring enrollment in e-mail systems, intranet systems, remote-access systems, computers and corresponding peripheral hardware may need to be ordered, telephones provisioned, office space allocated, and the like. Similarly, if an employee leaves the company, you must judiciously remove the user from all these systems and resources.
In light of this, promotions, transfers, mergers, acquisitions, divestitures, marriage, divorce, name changes, and so on, can cause substantial logistical problems that can not typically be solved with a simple drag and drop of directory objects from one domain to another. Instead, users or resources must generally be deleted from one domain and then completely re-created in another domain; not to mention the logistical problems caused by moving entire groups of users and/or resources between domains. Thus, in today's fast-paced world of mergers, acquisitions, divestitures, and reorganizations, ensuring that employees have proper access to company resources can be a full-time job for an army of information technology workers.
These resource provisioning activities traditionally occur within organizations in an uncoordinated and decentralized fashion, and often result in delays, duplication of administrative effort, and unnecessary expense. For example, the costs show up with an increasing number of calls to a help desk because directories aren't synchronized or because users can't access physical resources or applications. However, it's not just about cost and replication of effort; it's also about risk. The risks of provisioning in an uncoordinated and decentralized fashion become evident when users who are no longer with a company still exist in some of the directories and can access the company's valuable resources.
Many organizations have developed their own jury-rigged solutions to the problems of automating the provisioning process by using a workflow, which is a series of predefined actions or procedures to coordinate complex sequences of actions. Workflows have always been expensive to produce, inflexible, and difficult to maintain. For example, one problem with conventional procedures to implement workflows is that workflows are typically based on a “fire and forget” paradigm. The “fire” aspect means an individual such as a network administrator is generally required to manually identify and execute a particular workflow sequence to implement a predefined policy in response to a specific event. This is a problem because there can be any number of workflows used to implement policies within an organization. Locating a proper workflow to implement in a timely manner is not always a simple procedure and it is susceptible to human error.
The “forget” aspect of the fire-and-forget paradigm of conventional workflow implementation means that even though group policies are typically based on a domain or unit within an organization, no one particular entity such as a network administrator (typically has an easy way to predict which machines or resources will be affected by a workflow. This is especially true in a distributed networking environment, where peripheral devices may be added and removed from the network at any time. Additionally, because a workflow may consist of any number of long running operations that can take hours, weeks, or longer to complete, there is no easy way for an administrator to coordinate transactions and/or monitor statuses such as the success or failure of the tasks that are implemented by the workflow.
Moreover, once workflows have been implemented, it is typically not a simple task for an administrator to determine which particular workflow of multiple workflows was used to implement a particular policy that affected machines and/or resources.
For instance, consider that a particular workflow is executed to implement a policy granting one or more computers or users on a network access to specific network resources or physical facility resources to which the computers/users previously had no access. Afterward the workflow has been implemented, it is determined that one or more machines or users were erroneously granted access to those network resources or physical facilities. It may be crucial to organizational interests (e.g., security) to determine exactly which machines, users, and/or resources were affected by the workflow. However, to accomplish this it will be necessary to identify the particular workflow that resulted in the erroneous grant of resources. Unfortunately, traditional workflow systems and procedures do not typically provide an easy way for an administrator to identify such information.
These types of problems also arise within “hire-and-fire” scenarios within an organization. For instance, after a person leaves an organization, an administrator must typically coordinate the inverse of any provisioning that occurred from when the person was hired to the time that the person left the company's employment. The organization's provisioning may have been implemented by any number of various workflows. Unfortunately, traditional workflow systems and procedures do not typically provide an easy way for an administrator to identify the one or more workflows that may have been used to provision the person. Thus, any modification to the person's network and physical resource access, and any modification to associated business operations to reflect the persons new non-employee status is typically performed in an uncoordinated and decentralized fashion, possibly resulting in delays, duplication of administrative effort, unnecessary expense, and increased risk.
Yet another problem with traditional workflow implementations are that they are not typically “self-healing”, or self-correcting. This means that if a particular operation of a workflow fails in some manner, one or more corrective actions may not be taken in response to the failed operation. In other words, if a computer that is executing one or more aspects of a workflow malfunctions or for some other reason becomes unavailable, there is typically no mechanism to ensure that conditional aspects of a workflow that may have depended on un-implemented or failed aspects of the workflow have been satisfied. Additionally there is not mechanism to ensure that the un-implemented (or failed) aspects of the workflow are eventually implemented. This lack of a self-correcting behavior is especially important to consider in a distributed computing environment, wherein more than one computer, and possibly dozens, hundreds, or even thousands of computers may be involved in executing any one task or operation of a workflow.
The following arrangements and procedures address these and additional problems of traditional systems and procedures to define and implement workflows.